Universal Access To All Knowledge
Home Donate | Store | Blog | FAQ | Jobs | Volunteer Positions | Contact | Bios | Forums | Projects | Terms, Privacy, & Copyright
Search: Advanced Search
Anonymous User (login or join us)
Upload

Reply to this post | Go Back
View Post [edit]

Poster: Administrator, Curator, or StaffTom Anderson Date: Jan 24, 2003 12:32am
Forum: etree Subject: No wonder bandwith is an issue; here's the fix:

Change your php.ini or your documentroot .htaccess and add either of these lines, respectivly:
output_handler ="ob_gzhandler"
php_value output_handler "ob_gzhandler"

Right now your home page for audio is 127K!!!!! That's way too big. Adding these lines will reduce your http bandwidth for web pages by 90%.

Tom

Reply to this post
Reply [edit]

Poster: cortex Date: Jan 24, 2003 5:52am
Forum: etree Subject: Re: No wonder bandwith is an issue; here's the fix:

ah, gzip compression. that would certainly do the job

Reply to this post
Reply [edit]

Poster: Administrator, Curator, or StaffBrad Date: Jan 24, 2003 7:51am
Forum: etree Subject: Re: No wonder bandwith is an issue; here's the fix:

Interesting idea, Tom. Thanks for helping with expertise and brainstorming!

However, I'm not sure if the savings in bandwidth will outweigh the cpu load for gzipping all the documents served. www.archive.org is averaging ~12.5 GB(ytes)/day of traffic. It looks like about 25% of that is PHP, the rest being mostly images, which wouldn't be affected by this, but assuming that all of the traffic is php, that boils down to an average of 1 Mb(it)/second.

If we compress the data, and get 10-fold compression, (maybe optimistic?) we'll be saving ~900-1000Kb(its)/sec.

Also, since we've segmented audio downloads from the rest of the traffic(including www.archive.org) this won't have any impact on audio bandwidth. (The segmenting is a temporary solution, fyi.)

If we do decide to try this out, it seems like there are two paths:
*do performance/load testing before making the change, to see the CPU impact on the webserver, or,

* seat-of-the-pants: try it and get ready to undo the change if we see the cpu load spike out of control.

I'd vote for the second, as it seems low risk, but again, I'm not sure how much impact it will have.

Reply to this post
Reply [edit]

Poster: Administrator, Curator, or StaffTom Anderson Date: Jan 27, 2003 3:34am
Forum: etree Subject: Re: No wonder bandwith is an issue; here's the fix:

The cpu load for dynamic gzip is minimal. I belive it runs it all in only 5K of memory. There was a cpu problem in version 4.0beta2 or something but that issue is long-since fixed.

Reply to this post
Reply [edit]

Poster: Alex Prestin Date: Jan 25, 2003 10:59am
Forum: etree Subject: Re: No wonder bandwith is an issue; here's the fix:

Why not stop dynamically generating the discussion threads on the main page then? That would save a TON of time for people not interested in the discussions. Those who are could simply click one level further into the site. The discussion threads are easily the largest part of the front page and take the longest to load.

- A.P.

Reply to this post
Reply [edit]

Poster: Administrator, Curator, or StaffDiana Hamilton Date: Jan 25, 2003 12:26pm
Forum: etree Subject: Re: Forum message presentation

But if each forum were tucked into its little corner, people concerned with more than say etree (like general admins) would miss some important current issues, or else have to laboriously check every forum each time they drop by.

Also, the stacking by most recent makes it particularly easy to catch up on new issues too, without worrying that some of the recent posts may be hanging off "buried" older threads that are harder to pick up.

I always visit the archive.org front page to read messages, not the etree page.

...Oh wait, I think I just missed your point though, sorry! If you mean, just move the scroll of most recent all-forum posts to a new subpage off the main one, I could live with visiting that. :)

This post was modified by hamilton on 2003-01-25 20:26:56

Reply to this post
Reply [edit]

Poster: Administrator, Curator, or StaffJonathan Aizen Date: Jan 25, 2003 11:23pm
Forum: etree Subject: Re: No wonder bandwith is an issue; here's the fix:

The forums on each collection's page are intended to generate discussion and get people involved.

As one observant user point out, using CSS will reduce the size of the forum and so I intend, when time permits, to do this.

Reply to this post
Reply [edit]

Poster: Administrator, Curator, or Staffbrewster Date: Jan 26, 2003 10:37am
Forum: etree Subject: Re: No wonder bandwith is an issue; here's the fix:

I was a supporter of having the threads visible lots of the time. the pages load and display the top section without waiting for the forum section, so I think the loading should not be too painful for users if they are not interested in the forums.

since much of the archive materials is not modem friendly, I would imagine most are coming to us from high speed links.

-brewster

Reply to this post
Reply [edit]

Poster: Administrator, Curator, or Staffbrewster Date: Jan 24, 2003 9:02am
Forum: etree Subject: Re: No wonder bandwith is an issue; here's the fix:

I like the seat-of-the-pants approach as well. I think the real win would be helping users with a smaller download of the page.

-brewster